home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1007 < prev    next >
Text File  |  1995-07-25  |  50KB  |  1,356 lines

  1.  
  2. Network Working Group                                         Wayne McCoy
  3. Request for Comments: 1007                                       June 1987
  4.  
  5.  
  6.  
  7.                          MILITARY SUPPLEMENT
  8.  
  9.                                TO THE
  10.  
  11.                        ISO TRANSPORT PROTOCOL
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC is being distributed to members of the Internet community
  17.    in order to solicit comments on the Draft Military Supplement.
  18.    While this document may not be directly relevant to the research
  19.    problems of the Internet, it may  be of some interest to a number
  20.    of researchers and implementors. Distribution of this memor is
  21.    unlimited.
  22.  
  23.  
  24. 1. SCOPE
  25.  
  26. 1.1   Purpose.
  27.  
  28.    This document supplements the Transport Service and Protocol of the
  29.    International Standards Organization (ISO), IS 8072 and IS 8073,
  30.    respectively, and their formal descriptions by providing conventions,
  31.    option selections and parameter values to be used when the protocol
  32.    is operated within the scope of the applicability statement in
  33.    Paragraph 1.3 below.  Paragraph 1.4, below, describes the ISO
  34.    standards.  Full implementation detail is not provided in this
  35.    document, but reference is made to a separate document, entitled
  36.    "Implementation Guide for the ISO Transport Protocol", in which
  37.    guidance for implementation is given.
  38.  
  39. 1.2  Organization.
  40.  
  41.    Five sections comprise this supplement.  In Section 1, the role and
  42.    purpose of the Transport Protocol are stated and the international
  43.    standards upon which the protocol is based are described.  These
  44.    documents, as well as others supporting  the international standards
  45.    and this supplement are listed in  Section 2.  Other definitions not
  46.    already included in the international standards and supporting
  47.    documents are given in Section 3.  The international standards cover
  48.    a very wide variety of network environments and situations.  There
  49.    is, thus, a collection of options and parameters provided by the
  50.    standards which must be determined for specific uses.  Section 4
  51.    states the options and parameters relevant to those implementations
  52.    to which this supplement applies, and defines usage conventions.
  53.  
  54.  
  55.  
  56. McCoy                                                           [Page 1]
  57.  
  58. RFC 1007                                                       June 1987
  59.  
  60.  
  61.    Conventions for addressing and Transport connection reference
  62.    number usage and recovery of the Transport connection from peer
  63.    deactivation are covered in Section 5.
  64.  
  65. 1.3   Application.
  66.  
  67.    The use of the Transport Protocol Class 4 and the Protocol for
  68.    Providing the Connectionless-Mode Network Service (IS 8473) is
  69.    mandatory foruse in all DOD packet-switched data networks where
  70.    there is a potential for host-to-host connectivity across network
  71.    or subnetwork boundaries.  The term "network" as used here shall
  72.    include Local Area Networks but not integrated weapons systems.
  73.    The use of the Transport Protocol Class 4 and IS 8473 is
  74.    strongly encouraged, particularly  where a need for equipment
  75.    interchangeability or survivability is perceived. Use of the
  76.    Transport Protocol Class 4 and IS 8473 in weapons systems, where
  77.    such usage does not diminish required performance, is also
  78.    encouraged.
  79.  
  80. 1.4   International Standards Organization Transport Protocol.
  81.  
  82.    The international standard upon which this supplement is based is
  83.    described in four documents:
  84.  
  85.        a. IS 8072, the Transport Service Definition, which defines the
  86.           service that Transport provides to a user, described in
  87.           English text;
  88.  
  89.        b. WG4 N53, the Formal Description of the Transport Service, in
  90.           which the Transport Service is described using a formal
  91.           description language;
  92.  
  93.        c. IS 8073, the Transport Protocol, in which the protocol is
  94.           specified in English text; and
  95.  
  96.        d. N123, the formal description of the Transport Protocol, in
  97.           which the specification IS 8073 is written in a formal
  98.           description language.
  99.  
  100.    The ISO protocol has five classes of service, named Class 0 through
  101.    Class 4.  Only Classes 4 and 2 will apply to this supplement.  The
  102.    formal description language, Estelle, DP 9074, provides for protocol
  103.    descriptions in terms of communicating finite state automata. It
  104.    contains a subset language which corresponds to the international
  105.    standard Pascal.  The Class 4 protocol operation when supported by a
  106.    connectionless network service is described in an addendum to IS
  107.    8073, N3339(rev).
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115. McCoy                                                           [Page 2]
  116.  
  117. RFC 1007                                                       June 1987
  118.  
  119.  
  120. 2.  REFERENCED DOCUMENTS
  121.  
  122. 2.1  Issues of Documents.
  123.  
  124.    The following documents of the issue in effect on date of invitation
  125.    for bids or request for proposal form a part of this supplement to
  126.    the extent specified herein.
  127.  
  128.                  FED-STD-1037  - Federal Standard - 1037,
  129.                    Glossary of Telecommunication Terms.
  130.  
  131.             Implementation Guide for the ISO Transport Protocol
  132.  
  133. 2.2  Other Publications.
  134.  
  135.    The following documents form part of this standard to the extent
  136.    specified herin.  Unless otherwise indicated, the issue in effect on
  137.    the date of invitation for bids or request for proposal shall apply.
  138.  
  139.    IS 8072 - Information Processing Systems -
  140.         Open Systems Interconnection - Transport Service Definition.
  141.         Available from: ANSI ISO TC97/SC6 Secretariat 1430 Broadway
  142.         New York, NY 10018 (212) 354-3343
  143.  
  144.    IS 8073 - Information Processing Systems -
  145.         Open Systems Interconnection - Transport  Protocol
  146.         Specification. Available from ANSI (SC6 Secretariat).
  147.  
  148.    N3339(rev) - Draft Proposed Addendum to IS 8073
  149.         to Enable Class 4 Operation Over Connectionless Mode Network
  150.         Service as Defined in ISO/ISO 8348/AD1.  Available from ANSI
  151.         (SC6 Secretariat).
  152.  
  153.    DP 9074 - Estelle - A Formal Description
  154.         Technique Based on an Extended State Transition Model.
  155.         Available from ANSI (SC21 Secretariat), address as for SC6,
  156.         above.
  157.  
  158.    WG4 N53 - Information Processing Systems -
  159.         Open Systems Interconnection - Formal Description of IS 8072
  160.         in Estelle. (Working draft, ISO TC 97/SC 6/WG 4)
  161.  
  162.    N123 - Information Processing Systems -
  163.         Open Systems Interconnection - Formal Description of IS 8073
  164.         in Estelle. (Working draft, ISO TC 97/SC 6)
  165.  
  166.    IS 8473 - Information Processing Systems -
  167.         Data Communications - Protocol for Providing the
  168.         Connectionless-mode Network Service. Available from ANSI
  169.         (SC6 Secretariat).
  170.  
  171.  
  172.  
  173.  
  174. McCoy                                                           [Page 3]
  175.  
  176. RFC 1007                                                       June 1987
  177.  
  178.  
  179. 3. DEFINITIONS
  180.  
  181. 3.1   Definition of terms.
  182.  
  183.    The definition of terms used in this standard shall comply with
  184.    FED-STD-1037, ISO IS 8072, IS 8073 and IS 8473.  Other terms and
  185.    definitions unique to N3756, WG4 N53 and N3339(rev) appear in
  186.    those documents.
  187.  
  188. 3.2   Abbreviations and acronyms.
  189.  
  190.    The following abbreviations and acronyms are used in this
  191.    supplement:
  192.  
  193.      a.  ISO.  The International Standards Organization;
  194.  
  195.      b.  OSI.  Open Systems Interconnection;
  196.  
  197.      c.  TS.  Transport service;
  198.  
  199.      d.  TSAP.  Transport service access point;
  200.  
  201.      e.  NSAP.  Network service access point;
  202.  
  203.      f.  TPDU.  Transport protocol data unit;
  204.  
  205.      g.  CR.  Connect request;
  206.  
  207.      h.  CC.  Connect confirm;
  208.  
  209.      i.  DR.  Disconnect request;
  210.  
  211.      j.  ER.  Error;
  212.  
  213.      k.  AK.  Acknowledgement;
  214.  
  215.      l.  IP.  Internetwork protocol;
  216.  
  217.      m.  LAN.  Local area network.
  218.  
  219.      n.  CONS. Connection oriented network service.
  220.  
  221.      o.  CLNS. Connectionless network service.
  222.  
  223.      (Other provisions of this Section are under consideration.)
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233. McCoy                                                           [Page 4]
  234.  
  235. RFC 1007                                                       June 1987
  236.  
  237.  
  238. 4. GENERAL REQUIREMENTS
  239.  
  240. 4.1   Conformance.
  241.  
  242.    Implementations to which this supplement applies shall satisfy the
  243.    conformance requirements (Clause 14, of IS 8073 and N3339(rev), as
  244.    adapted for this supplement) in the following statements.
  245.  
  246.      a.  A system claiming to implement the procedures specified
  247.          in this standard shall comply with the requirements in
  248.          b. - d., below.
  249.  
  250.      b.  The system shall implement:
  251.  
  252.          b.1  Class 2 or Class 0 or both, if operated over a connection
  253.               oriented network service; or
  254.  
  255.          b.2  Class 4 if operated over a connectionless network service.
  256.  
  257.      c.  If the system implements Class 4, it shall also implement
  258.          Class 2, if it is operated over a connection oriented network
  259.          service.  Class 2 shall not be implemented if operation is
  260.          exclusively over a connectionless network service.
  261.  
  262.      d.  For each class which the system claims to implement, the
  263.          system shall be capable of:
  264.          d.1  initiating CR TPDUs or responding to CR TPDUs with TPDUs
  265.               or both;
  266.  
  267.          d.2  responding to any other TPDU and operating network
  268.               service in accordance with procedures for the class;
  269.  
  270.          d.3  operating all the procedures for the class listed as
  271.               mandatory in the Provisions of Options table below;
  272.  
  273.          d.4  operating those procedures for the class, listed as as
  274.               optional in the Provisions of Options table, for which
  275.               conformance is claimed; and
  276.  
  277.          d.5  handling all TPDUs of lengths up to the lesser value of:
  278.  
  279.               d.5.1  the maximum length for the class;
  280.  
  281.               d.5.2  the maximum for which conformance is claimed.
  282.  
  283.      e.  Claims of conformance shall state:
  284.  
  285.          e.1  whether or not operation over connectionless service is
  286.               implemented;
  287.  
  288.          e.2  which class or classes of protocol are implemented, if
  289.  
  290.  
  291.  
  292. McCoy                                                           [Page 5]
  293.  
  294. RFC 1007                                                       June 1987
  295.  
  296.  
  297.               operation over a connection oriented network is
  298.               implemented;
  299.  
  300.          e.3  whether the system is capable of initiating or responding
  301.               to CR TPDUs or both;
  302.  
  303.          e.4  which of the procedures listed in the Provisions of
  304.               Options table are implemented;
  305.  
  306.          e.5  the maximum size of TPDU implemented; the value shall be
  307.               chosen from the following list and all values in the list
  308.               which are less than this maximum shall be implemented:
  309.  
  310.               128, 256, 512, 1024, 2048, 4096, or 8192 octets.
  311.  
  312.    Provision of options (adapted from IS 8073, Table 9)
  313.     __________________________________________________________________
  314.    |        PROCEDURE         |     CLASS 2        |     CLASS 4     |
  315.    |__________________________|____________________|_________________|
  316.    |                          |                    |                 |
  317.    |TPDU with checksum        |not applicable      |mandatory        |
  318.    |TPDU without checksum     |mandatory           |optional         |
  319.    |__________________________|____________________|_________________|
  320.    |                          |                    |                 |
  321.    |Expedited data transfer   |mandatory           |mandatory        |
  322.    |No expedited data transfer|mandatory           |mandatory        |
  323.    |__________________________|____________________|_________________|
  324.    |                          |                    |                 |
  325.    |Flow control in Class 2   |mandatory           |not applicable   |
  326.    |No flow control in Class 2|optional            |not applicable   |
  327.    |__________________________|____________________|_________________|
  328.    |                          |                    |                 |
  329.    |Normal formats            |mandatory           |mandatory        |
  330.    |Extended formats          |optional            |optional         |
  331.    |__________________________|____________________|_________________|
  332.  
  333.  
  334.    The explicit manner in which implementations, to which this
  335.    supplement applies, shall satisfy these conformance statements is
  336.    given in Paragraph 4.4.  The options are described in more detail in
  337.    Paragraph 4.3.
  338.  
  339. 4.2   Transport Service access parameters.
  340.  
  341.    Each of the services of transport has parameters that identify
  342.    communicating peers, express options for operation of the transport
  343.    connection, or transmit data from one peer user to the other.  The
  344.    conventions for these parameters for usage in implementations to
  345.    which this supplement applies are given below.
  346.  
  347.  
  348.  
  349.  
  350.  
  351. McCoy                                                           [Page 6]
  352.  
  353. RFC 1007                                                       June 1987
  354.  
  355.  
  356. 4.2.1   Connect Service.
  357.  
  358.    The Connect Service is summarized below (refer to IS 8072 for
  359.    detailed discussion):
  360.  
  361.  
  362.    __________________________________________________________________
  363.    |             Primitives                        Parameters       |
  364.    |________________________________________________________________|
  365.    | T-CONNECT          request     |  Called Address,              |
  366.    |                    indication  |  Calling Address,             |
  367.    |                                |  Expedited Data Option,       |
  368.    |                                |  Quality of Service,          |
  369.    |                                |  TS User-Data                 |
  370.    |________________________________|_______________________________|
  371.    | T-CONNECT          response    |  Responding Address,          |
  372.    |                    confirm     |  Quality of Service,          |
  373.    |                                |  Expedited Data Option,       |
  374.    |                                |  TS User-Data                 |
  375.    |________________________________|_______________________________|
  376.  
  377.    Conventions for Called Address, Calling Address and Responding
  378.    Address will appear in Paragraph 5.1.1.  Use of the Expedited
  379.    Data Option is dependent on the nature of the transport user;
  380.    this supplement does not define how transport users will decide
  381.    on such usage.  The parameters that define Quality of Service are
  382.    discussed in IS 8072.  However, the manner in which these
  383.    parameters are to be applied in an implementation issue , and the
  384.    mechanisms to be used to maintain the requested quality of sevice
  385.    are not defined.  It is thus recommended that these parameters
  386.    not be used in implementations until such time that usage
  387.    definition exists. The amount of data passed in TS User-Data is
  388.    constrained to 32 octets or less.  (This TS User-Data parameter
  389.    shall not be used for any data that requires any security protection
  390.    whatever.)  No implementation is required to be able to send such
  391.    data received from its user, but each implementation shall be
  392.    capable of passing data received from the remote peer user during
  393.    connection establishment to its user.
  394.  
  395. 4.2.2   Disconnect Service.
  396.  
  397.    __________________________________________________________________
  398.    |             Primitives                        Parameters       |
  399.    |________________________________________________________________|
  400.    | T-DISCONNECT       request     |  TS User-Data                 |
  401.    |________________________________|_______________________________|
  402.    | T-DISCONNECT       indication  |  TS User-Data,                |
  403.    |                                |  Disconnect reason            |
  404.    |________________________________|_______________________________|
  405.  
  406.    The Disconnect Service is abrupt in the sense that data may be lost
  407.  
  408.  
  409.  
  410. McCoy                                                           [Page 7]
  411.  
  412. RFC 1007                                                       June 1987
  413.  
  414.  
  415.    whenever the service is invoked.  Transport user processes should
  416.    therefore ensure that all data intended to be received has in fact
  417.    been received before issuing a T-DISCONNECT-request.  The data used
  418.    in the TS User-Data parameter is constrained to be 64 octets or less
  419.    in length.  (The TS User-Data parameter shall not be used for data
  420.    that requires any security protection whatever.)  Disconnect reasons
  421.    are discussed in IS 8073, and reasons other than those listed in IS
  422.    8073 are permitted.
  423.  
  424. 4.2.3   Data Transfer Service.
  425.    __________________________________________________________________
  426.    |             Primitives                      Parameters         |
  427.    |________________________________________________________________|
  428.    | T-DATA             request     |  TS User-Data                 |
  429.    |                    indication  |                               |
  430.    |________________________________|_______________________________|
  431.  
  432.    The length of the data that is carried by the TS User-Data parameter
  433.    is not constrained by the ISO Standard, but interface considerations
  434.    may impose practical limits.  This is discussed further in the
  435.    Implementors guide, Part 3.1.  For the purposes of this supplement,
  436.    the TS User-Data parameter in this service is considered to be
  437.    protected and should be used for any data requiring security
  438.    protection.
  439.  
  440. 4.2.4   Expedited Data Service.
  441.  
  442.    __________________________________________________________________
  443.    |               Primitives                   Parameters          |
  444.    |________________________________________________________________|
  445.    | T-EXPEDITED-DATA   request     |  TS User-Data                 |
  446.    |                    indication  |                               |
  447.    |________________________________|_______________________________|
  448.  
  449.    The TS User-Data parameter is constrained to be no longer than
  450.    16 octets and shall not be used for data requiring any security
  451.    protection whatever.  The T-EXPEDITED-DATA-request cannot be used
  452.    whenever non-use of expedited data was called for in either the
  453.    T-CONNECT-request or T-CONNECT-response primitive.
  454.  
  455. 4.3   Options.
  456.  
  457.    The protocol described in IS 8073 and N3756 permits certain options
  458.    which qualify or enhance the service to be provided.  Negotiated
  459.    options are those which both communicating peer transport entities
  460.    agree upon during connection establishment. Local options are those
  461.    which apply to a particular implementation of transport that may
  462.    be used to enhance performance, optimize resource utilization or
  463.    improve resilience to network failures. The election of a local
  464.    option is invisible to the remote peer entity.
  465.  
  466.  
  467.  
  468.  
  469. McCoy                                                           [Page 8]
  470.  
  471. RFC 1007                                                       June 1987
  472.  
  473.  
  474. 4.3.1  Negotiated options.
  475.  
  476.    The options in IS 8073 that shall be negotiated between peer
  477.    transport entities are given in the following list.  The elections
  478.    of these options to be taken in  an implementation to which this
  479.    supplement applies are defined in Paragraph 4.4.
  480.  
  481.  
  482.      a.   a. Class of service--agreement as to one of five classes of
  483.           transport service, depending on which classes are supported by
  484.           the entities, the quality of the network service available and
  485.           the degree of resilience to network errors and failure
  486.           required by the peer transport users.
  487.  
  488.      b.   b. Use of extended formats--agreement to use or not use
  489.           extended formats for sequence numbering and flow control
  490.           credit; normal formats provide sequence numbers in the range 0
  491.           - (2**7 - 1) and flow control credit in the range 0 - (2**15 -
  492.           1); extended  formats provided sequence numbers in the range 0
  493.           - (2**31 - 1)  and credit in the range 0 - (2**16 - 1).
  494.  
  495.      c.   Use of expedited data transfer--agreement to use or not to use
  496.           expedited data transfer during normal data transfer
  497.           procedures.
  498.  
  499.      d.   Maximum size of protocol data units to be exchanged--agreement
  500.           to limit size of exchanged protocol data units, depending on
  501.           buffer resources that the entities have and network quality of
  502.           service; values negotiated are in the range 2**7 - 2**13
  503.           octets (total length).
  504.  
  505.      e.   Use of checksum--agreement to use or not to use a 16-bit
  506.           checksum on each protocol data unit exchange between the
  507.           entities, depending on expected residual error rate in the
  508.           network service used.
  509.  
  510.      f.   Protection parameters--agreement as to how protection will be
  511.           defined and maintained on the transport connection; these
  512.           parameters are defined by the communicants which elect to use
  513.           them.
  514.  
  515.      g.   Use of flow control in Class 2--agreement to use or not to use
  516.           flow control in Class 2 when Class 2 operation has been
  517.           negotiated. Conformance to the ISO Standard requires that if
  518.           Class 4 is supported over CONS, then Class 2 shall also be
  519.           supported.
  520.  
  521.      h.   Service quality parameters--agreement as to the quality of
  522.           service to be expected on the transport connection; the ISO
  523.           Standard does not state how these parameters are to be used by
  524.           the transport entities or their users.
  525.  
  526.  
  527.  
  528. McCoy                                                           [Page 9]
  529.  
  530. RFC 1007                                                       June 1987
  531.  
  532.  
  533. 4.3.2   Local options, Class 2.
  534.  
  535.    The options that an implementor may decide in a particular Class 2
  536.    implementation are given in the following list.  Recommendations
  537.    and requirements for these options for the purposes of this
  538.    this supplement are given in Paragraph 4.5.1.
  539.  
  540.  
  541.      a.   Multiplexing on network connection--for better usage of of
  542.           network resources, an implementation may elect to share a
  543.           network connection among two or more transport connections.
  544.  
  545.      b.   Acknowledgement strategy--an implementation is not required by
  546.           IS 8073 to use any particular strategy for sending
  547.           acknowledgements for received data:  each data transfer
  548.           protocol data unit may be explicitly acknowledged (one-for-
  549.           one) or may be implicitly acknowledged by a group
  550.           acknowledgement (one-for-N).
  551.  
  552.      c.   Concatenation of protocol data units--when network service
  553.           data units are large compared to the protocol data units to be
  554.           sent, an implementation may elect to concatenate these
  555.           protocol data units into a single network service data unit.
  556.  
  557.      d.   Lockup prevention timer--when the wait-before-closing state is
  558.           entered, there is a possibility of deadlock if the peer
  559.           transport entity never responds to the CR TPDU.  The standard
  560.           provides for an optional timer to alleviate this situation.
  561.  
  562. 4.3.3   Local options, Class 4.
  563.  
  564.    The options that an implementor may decide in a particular Class 4
  565.    implementation are given in the list below.  Recommendations and
  566.    requirements for use of these options in implementations to which
  567.    this supplement applies are given in Paragraph 4.5.2.
  568.  
  569.  
  570.      a.   Withdrawal of flow control credit--when supporting several
  571.           connections of differing precedence or priority, resource
  572.           management must be practiced so as to maintain the precedence
  573.           or priority relationships.
  574.  
  575.      b.   Flow control confirmation--when flow control credit is
  576.           reduced, extra delay may be encountered because
  577.           acknowledgements carrying new flow control information are
  578.           lost; this procedure aids in speeding up resynchronization of
  579.           the flow control.
  580.  
  581.      c.   Subsequenced acknowledgements--when the flow control window
  582.           has been closed this procedure alleviates ambiguity due to
  583.           lost or out-of-order acknowledgements.
  584.  
  585.  
  586.  
  587. McCoy                                                          [Page 10]
  588.  
  589. RFC 1007                                                       June 1987
  590.  
  591.  
  592.      d.   Splitting over network connection--when operating over a
  593.           connection-oriented network service, a Class 4 implementation
  594.           is permitted to use more than one network connection, for
  595.           better performance and better resilience to network connection
  596.           failure.
  597.  
  598.      e.   Acknowledgement strategy--an implementation is not required by
  599.           the standard to use any particular strategy for sending
  600.           acknowledgements for received data:  each data transfer
  601.           protocol data unit may be explicitly acknowledged (one-for-
  602.           one) or may be implicitly acknowledged by a group
  603.           acknowledgement (one-for-N).
  604.  
  605.      f.   Wait-before-closing state--when a connect request has been
  606.           sent to the peer and the user has requested a disconnection
  607.           before the connect confirmation has been received, an
  608.           implementation may elect to wait until the confirmation has
  609.           arrived before sending the disconnection request to the peer,
  610.           to ensure positive identification of the connection to be
  611.           released.
  612.  
  613.      g.   Multiplexing on network connection--for better usage of
  614.           network resources, an implementation may elect to share a
  615.           network connection among two or more transport connections.
  616.  
  617.  
  618.      h.   Concatenation of protocol data units--when network service
  619.           data units are large compared to the protocol data units to be
  620.           sent, an implementation may elect to concatenate these
  621.           protocol data units into a single network service data unit.
  622.  
  623.      i.   Checksum algorithm--the Fletcher checksum algorithm provided
  624.           in an annex to the standard is not part of the standard and is
  625.           provided for information only.  The checksum algorithm used
  626.           nature of network errors expected and need only satisfy the
  627.           summation criterion given in the standard.
  628.  
  629.      j.   Send network RESET when bad checksum received--it may not be
  630.           possible to know with certainty which of several transport
  631.           connections multiplexed on a network connection is to receive
  632.           a protocol data unit which carries a bad checksum.  A N-RESET
  633.           or N-DISCONNECT may be sent on the network connection to all
  634.           transport entities on the connection to indicate the error.
  635.  
  636.      k.   Protocol data unit retransmission policy--protocol data units
  637.           for which no acknowledgement has been received may be
  638.           retransmitted in case the originals were never received.
  639.           Whether to retransmit only the oldest unacknowledged protocol
  640.           data unit or all those that are outstanding has implications
  641.           for buffer management in the sending entity and for
  642.           utilization of the bandwidth in the network transmission
  643.  
  644.  
  645.  
  646. McCoy                                                          [Page 11]
  647.  
  648. RFC 1007                                                       June 1987
  649.  
  650.  
  651.           medium.
  652.  
  653.  
  654. 4.4   Negotiations.
  655.  
  656.    Paragraph 4.2.1 lists those options that shall be negotiatied by
  657.    communicating transport entities.  Below,  conventions are given for
  658.    these options, in usage to which this  supplement applies.  These
  659.    requirements reflect the conformance statement of IS 8073 and the
  660.    needs of the DOD.
  661.  
  662. 4.4.1   Options.
  663.  
  664. 4.4.1.1   Class of service.
  665.  
  666.      a.   An implementation operating on CONS shall be capable of
  667.           offering Class 2 and may optionally support Class 0.
  668.  
  669.      b.   An implementation shall not respond by a proposal of Class 0
  670.           and shall not respond by a proposal of Class 2 if the connect
  671.           request was received on a CLNS.
  672.  
  673.      c.   An implementation may offer Class 2 as an alternative class of
  674.           operation in a connect request when operating over CONS. No
  675.           alternative class may be offered if operation over a CLNS.
  676.  
  677.      d.   An implementation shall respond to a connect request that
  678.           proposes Class 1 or 3 as primary choice with a disconnect
  679.           request, reason code 128+2 (see p. 87 of IS 8073).
  680.  
  681.      e.   An implementation shall not propose Class 1 or Class 3 in
  682.           response to a connect request carrying Class 1 or Class 3 as
  683.           an alternative class of service.
  684.  
  685.      f.   An implementation which proposes Class 4 in a connect request
  686.           need not accept a proposal for Class 2 from its peer if Class
  687.           2 was not offered as an alternative in the connect request, or
  688.           if operation is over a CLNS. Class 2 shall be accepted when
  689.           proposed by the responding peer if it  was offered as an
  690.           alternative in the connect request.
  691.  
  692. 4.4.1.2   Extended formats.
  693.  
  694.      a.   An implementation shall always propose use of extended formats
  695.           when either Class 4 or Class 2 is proposed in a connect
  696.           request.
  697.  
  698.      b.   An implementation shall always accept the use of extended
  699.           formats when so proposed in a received connect request.
  700.  
  701.  
  702.  
  703.  
  704.  
  705. McCoy                                                          [Page 12]
  706.  
  707. RFC 1007                                                       June 1987
  708.  
  709.  
  710. 4.4.1.3   Expedited data.
  711.  
  712.      a.   Use of expedited data is subject to negotiation by users of
  713.           Transport Service.
  714.  
  715.      b.   Expedited data shall be supported in Class 2.
  716.  
  717. 4.4.1.4   Maximum protocol data unit size.
  718.  
  719.    (The provisions of this paragraph are under consideration.)
  720.  
  721. 4.4.1.5   Use of checksum.
  722.  
  723.    An implementation shall propose use of checksums consistent with the
  724.    expected quality of service and security requirements.
  725.  
  726.  
  727.      a.   Checksums should be used when operating with the IP on
  728.           catenated networks.
  729.  
  730.      b.   Checksums should not be used if high performance is required,
  731.           except when required by high error rates in the network
  732.           service.
  733.  
  734.      c.   Checksums should always be used when any encryption is being
  735.           used.
  736.  
  737. 4.4.1.6   Protection parameters.
  738.  
  739.    Use of the security parameters is not defined in this supplement.
  740.  
  741. 4.4.1.7   Use of flow control in Class 2.
  742.  
  743.  
  744.      a.   An implementation shall always propose the use of flow control
  745.           in Class 2 whenever Class 2 is proposed as either primary or
  746.           alternative choice of service.
  747.  
  748.      b.   An implementation shall accept use of flow control in Class 2
  749.           whenever negotiation to Class 2 occurs.
  750.  
  751.  
  752. 4.4.1.8  Service quality parameters.
  753.  
  754.  
  755.      a.   Use of the service quality parameters in the CR and CC
  756.           protocol data units is not defined except for the residual
  757.           error rate parameter and the priority parameter.
  758.  
  759.      b.   Residual error rate (the use of this parameter is under
  760.           consideration).
  761.  
  762.  
  763.  
  764. McCoy                                                          [Page 13]
  765.  
  766. RFC 1007                                                       June 1987
  767.  
  768.  
  769.      c.   Priority (the use of this parameter is under consideration).
  770.  
  771. 4.4.2   Parameters.
  772.  
  773.           This paragraph defines the values to be used in the CR and CC
  774.           TPDUs.
  775.  
  776. 4.4.2.1   Class 2 parameters.
  777.  
  778. 4.4.2.1.1   Connect request (CR) protocol data unit.
  779.  
  780. 4.4.2.1.1.1   Fixed part of header.
  781.  
  782.  
  783.      a.   Connect request code: as in IS 8073.
  784.  
  785.      b.   Initial credit allocation: this field defines the number of
  786.           TPDUs offered as initial credit by the connection initiator.
  787.           Since the field is of length  4, the maximum credit that can
  788.           be initially offered is limited to 15.  These TPDUs are
  789.           constrained in length to the maximum size defined in the TPDU
  790.           size field, listed below in Paragraph 4.4.2.1.1.2.
  791.  
  792.      c.   Destination reference: as in IS 8073.
  793.  
  794.      d.   Source reference: this reference shall be selected pursuant to
  795.           the provisions of Paragraph 5.2.1.
  796.  
  797.      e.   Class and option: the class field shall take binary value
  798.           0010; the option field shall take binary value 0010. (These
  799.           values select Class 2, and the options of extended formats and
  800.           flow control in Class 2.)
  801.  
  802.  
  803. 4.4.2.1.1.2   Variable part of header.
  804.  
  805.  
  806.      a.   TSAP identifiers: the parameter values shall follow the
  807.           conventions given in Paragraphs 5.1.1 and 5.1.2.
  808.  
  809.      b.   TPDU size: (The values to be used are under consideration.)
  810.  
  811.      c.   Version number: as in IS 8073.
  812.  
  813.      d.   Protection parameters: should not be used.
  814.  
  815.      e.   Checksum: shall not be used.
  816.  
  817.      f.   Additional options: this field shall take binary value 0001 if
  818.           the initiating user has proposed the use of expedited data,
  819.           and shall take value 0000 otherwise.
  820.  
  821.  
  822.  
  823. McCoy                                                          [Page 14]
  824.  
  825. RFC 1007                                                       June 1987
  826.  
  827.  
  828.      g.   Alternative protocol classes: this field shall not be used
  829.           unless Class 0 is to be proposed as an alternate class of
  830.           operation.
  831.  
  832.      h.   Throughput: should not be used.
  833.  
  834.      i.   Residual error rate: should not be used.
  835.  
  836.      j.   Priority: (Use of this parameter is under consideration.)
  837.  
  838.      k.   Transit delay: should not be used.
  839.  
  840. 4.4.2.1.1.3  User data.
  841.  
  842.    The CR TPDU shall not carry user data which has any requirement
  843.    whatever for security protection.
  844.  
  845. 4.4.2.1.2   Connect Confirm (CC) TPDU.
  846.  
  847. 4.4.2.1.2.1   Fixed part of header.
  848.  
  849.  
  850.      a.   Connect confirm code: as in IS 8073.
  851.  
  852.      b.   Initial credit allocation: same as Paragraph 4.4.2.1.1.1.
  853.  
  854.      c.   Destination reference: this reference shall be the "Source
  855.           reference" number from the received CR TPDU.
  856.  
  857.      d.   Source reference: this reference shall be selected pursuant to
  858.           the provisions of Paragraph 5.2.1.
  859.  
  860.      e.   Class and option: the class field shall take binary value 0010
  861.           and the option field shall take binary value  0010 (selects
  862.           Class 2 and options of extended formats and flow control in
  863.           Class 2).
  864.  
  865.  
  866. 4.4.2.1.2.2   Variable part of header.
  867.  
  868.  
  869.      a.   TSAP identifier(s): the parameter values shall follow the
  870.           conventions given in Paragraphs 5.1.1 and 5.1.2.
  871.  
  872.      b.   b. TPDU size: (The values for this parameter are under
  873.           consideration.)
  874.  
  875.      c.   Version number: as in  IS 8073.
  876.  
  877.      d.   Protection parameters: should not be used.
  878.  
  879.  
  880.  
  881.  
  882. McCoy                                                          [Page 15]
  883.  
  884. RFC 1007                                                       June 1987
  885.  
  886.  
  887.      e.   Checksum : shall not be used.
  888.  
  889.      f.   Additional options: This field shall take binary value 0001 if
  890.           the responding transport entity has proposed the use of
  891.           expedited data, and shall take binary value 0000 otherwise.
  892.  
  893.      g.   Alternative protocol classes: shall not be used.
  894.  
  895.      h.   Throughput: should not be used.
  896.  
  897.      i.   Residual error rate: should not be used.
  898.  
  899.      j.   Priority: (The use of this parameter is under consideration.)
  900.  
  901.      k.   Transit delay: should not be used.
  902.  
  903. 4.4.2.1.2.3   User data.
  904.  
  905.      The CC TPDU shall not carry any data which has any requirement
  906.      whatever for security protection.
  907.  
  908. 4.4.2.2   Class 4 parameters.
  909.  
  910. 4.4.2.2.1  Connect request (CR) TPDU.
  911.  
  912. 4.4.2.2.1.1   Fixed part of header.
  913.  
  914.  
  915.      a.   Connect request code: as in IS 8073.
  916.  
  917.      b.   Initial credit allocation: this field defines the number of
  918.           TPDUs offered as initial credit by the connection initiator.
  919.           Since the field is of length 4, the maximum credit that can be
  920.           initially offered is limited to 15. These TPDUs are
  921.           constrained in length to the maximum size defined in the TPDU
  922.           size field, listed below in Paragraph 4.4.2.2.1.2.
  923.  
  924.      c.   Destination reference: as in  IS 8073.
  925.  
  926.      d.   Source reference: this reference shall be selected pursuant to
  927.           the provisions of Paragaph 5.2.1.
  928.  
  929.      e.   Class and option: the class field shall take binary value
  930.           0100; the option field shall take binary value 0010. (These
  931.           values select Class 4, and the options  of extended formats
  932.           and flow control in Class 2.  This latter option is ignored if
  933.           the class negotiated is Class 2.)
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941. McCoy                                                          [Page 16]
  942.  
  943. RFC 1007                                                       June 1987
  944.  
  945.  
  946. 4.4.2.2.1.2   Variable part of header.
  947.  
  948.  
  949.      a.   TSAP identifiers: the parameter values shall follow the
  950.           conventions given in Paragraphs 5.1.1 and 5.1.2.
  951.  
  952.      b.   PDU size: (The values for this parameter are under
  953.           consideration.)
  954.  
  955.      c.   Version number: as in IS 8073.
  956.  
  957.      d.   Protection parameters: should not be used.
  958.  
  959.      e.   Checksum: if Class 4 has been selected, this parameter may be
  960.           used.  If Class 2 (or Class) has been selected, this parameter
  961.           shall not be used.
  962.  
  963.      f.   Additional options: this field shall take binary value 0001 if
  964.           the initiating user has proposed the use of expedited data,
  965.           and shall take binary value 0000 otherwise.
  966.  
  967.      g.   Alternative protocol classes: this field shall be used only if
  968.           Class 2 (or Class 0) is to be proposed as an alternate class
  969.           of operation, conformant to the conditions of Paragraph
  970.           4.4.1.1.  If Class 2 is proposed, the field shall take binary
  971.           value 00000010 (1 octet).
  972.  
  973.      h.   Acknowledge time:  should not be used.
  974.  
  975.      i.   Throughput: should not be used.
  976.  
  977.      j.   Residual error rate: (The use of this parameter is under
  978.           consideration.)
  979.  
  980.      k.   Priority: (The use of this parameter is under consideration.)
  981.  
  982.      l.   Transit delay: should not be used.
  983.  
  984. 4.4.2.2.1.3   User data.
  985.  
  986.      The CR TPDU shall not carry user data which has any requirement
  987.      whatever for security protection.
  988.  
  989. 4.4.2.2.2   Connect confirm (CC) TPDU.
  990.  
  991. 4.4.2.2.2.1   Fixed part of header.
  992.  
  993.      a.   Connect confirm code: as in IS 8073.
  994.  
  995.      b.   Initial credit allocation: same as Paragraph 4.4.2.2.1.1.b.
  996.  
  997.  
  998.  
  999.  
  1000. McCoy                                                          [Page 17]
  1001.  
  1002. RFC 1007                                                       June 1987
  1003.  
  1004.  
  1005.      c.   Destination reference: this reference shall be the number in
  1006.           "Source reference" from the received CR TPDU.
  1007.  
  1008.      d.   Source reference: this reference shall be selected pursuant to
  1009.           the provisions of Paragraph 5.2.1.
  1010.  
  1011.      e.   Class and option: if Class 2 has been selected, then the class
  1012.           field shall take binary value 0010 and the option field shall
  1013.           take binary value 0010.  If Class 4 has been selected, then
  1014.           the class field shall take binary value 0100 and the option
  1015.           field shall take binary value 0010.
  1016.  
  1017. 4.4.2.2.1.2  Variable part of header.
  1018.  
  1019.      a.   TSAP identifier(s): the parameters values shall follow the
  1020.           conventions given in Paragraphs 5.1.1 and 5.1.2.
  1021.  
  1022.      b.   TPDU size: (The values for this parameter are under
  1023.           consideration.)
  1024.  
  1025.      c.   Version number: as in IS 8073.
  1026.  
  1027.      d.   Protection parameters: should not be used.
  1028.  
  1029.      e.   Checksum: if Class 4 has been selected, this parameter may be
  1030.           used. If Class 2 (or Class 0) has been selected, this
  1031.           parameter shall not be used.
  1032.  
  1033.      f.   Additional options: if Class 4 or Class 2 has been selected,
  1034.           this field shall take binary value 0001 if the responding user
  1035.           has proposed use of expedited data and shall take binary value
  1036.           0000 otherwise.
  1037.  
  1038.      g.   Alternate protocol classes: shall not be used.
  1039.  
  1040.      h.   Acknowledgement time: should not be used.
  1041.  
  1042.      i.   Throughput: should not be used.
  1043.  
  1044.      j.   Residual error rate: (The use of this parameter is under
  1045.           consideration.)
  1046.  
  1047.      k.   Priority: (The use of this parameter is under consideration.)
  1048.  
  1049.      l.   Transit delay: should not be used.
  1050.  
  1051. 4.4.2.2.1.3   User data.
  1052.  
  1053.    The CC TPDU shall not carry user data which has any requirement
  1054.    whatever for security protection.
  1055.  
  1056.  
  1057.  
  1058.  
  1059. McCoy                                                          [Page 18]
  1060.  
  1061. RFC 1007                                                       June 1987
  1062.  
  1063.  
  1064. 4.5   Use of local options.
  1065.  
  1066.    The paragraphs that follow give policy and guidance in the election
  1067.    of local options.
  1068.  
  1069. 4.5.1   Local options, Class 2.
  1070.  
  1071. 4.5.1.1   Multiplexing.
  1072.  
  1073.    Any Class 2 connections may be multiplexed on the same network
  1074.    connection to the limits provided by the network service.
  1075.    Multiplexing Class 2 and Class 4 connections together on the same
  1076.    network connection is not recommended.
  1077.  
  1078. 4.5.1.2   Acknowledgement strategy.
  1079.  
  1080.    (The provisions of this paragraph are under consideration.)
  1081.  
  1082. 4.5.1.3   Concatenation.
  1083.  
  1084.    This permits placing certain TPDUs into a single network service
  1085.    data unit with a data-bearing TPDU.  It is useful for reducing
  1086.    the overhead of separate transmission of the individual TPDUs.
  1087.  
  1088. 4.5.1.4   Lockup prevention timer.
  1089.  
  1090.    It is strongly recommended that this timer be used for all Class 2
  1091.    connections.  A description of the timer has been included in the
  1092.    transport formal description.  (This timer corresponds to the
  1093.    optional TS1 timer that IS 8073 recommends.)
  1094.  
  1095. 4.5.1.5   Treatment of protocol errors.
  1096.  
  1097.    Protocol errors detected by a Class 2 transport connection shall
  1098.    result in that connection being terminated, without sending an ER
  1099.    TPDU.
  1100.  
  1101. 4.5.1.6   Action on receipt of Error transport protocol data unit.
  1102.  
  1103.    The receipt of an ER TPDU for a Class 2 transport connection shall
  1104.    cause immediate termination of that transport connection.
  1105.  
  1106. 4.5.2   Local options, Class 4.
  1107.  
  1108. 4.5.2.1   Withdrawal of flow control credit.
  1109.  
  1110.    Because of the need to serve transport connections of various
  1111.    levels of operating priority, an implementation shall support
  1112.    the withdrawal of flow control credit from any Class 4 transport
  1113.    connection as a means of managing resource allocation among
  1114.    Class 4 connections.
  1115.  
  1116.  
  1117.  
  1118. McCoy                                                          [Page 19]
  1119.  
  1120. RFC 1007                                                       June 1987
  1121.  
  1122.  
  1123. 4.5.2.2   Flow control confirmation.
  1124.  
  1125.    The requirement to support withdrawal of flow control credit
  1126.    strongly indicates the need to use flow control confirmation.
  1127.    An implementation should support and use the flow control
  1128.    confirmation procedures of IS 8073, consistent with quality of
  1129.    service and other requirements.
  1130.  
  1131. 4.5.2.3   Subsequenced acknowledgements.
  1132.  
  1133.    The possibility of credit withdrawal strongly indicates the
  1134.    requirement for subsequence numbers on acknowledgements.  An
  1135.    implementation shall support and use subsequence numbers as
  1136.    defined in IS 8073.
  1137.  
  1138. 4.5.2.4   Splitting over network connection.
  1139.  
  1140.    Implementations may use splitting as necessary or useful in the
  1141.    operating environment. (Splitting is defined only for operation
  1142.    over a CONS.
  1143.  
  1144. 4.5.2.5   Acknowledgement strategy.
  1145.  
  1146.    (The provisions of this paragraph are under consideration.)
  1147.  
  1148. 4.5.2.6   Wait-before-closing state.
  1149.  
  1150.    It is recommended that this state be used.  A lockup prevention
  1151.    timer, such as used in Class 2, is not necessary, since the CR
  1152.    TPDU retransmission timer serves this purpose.
  1153.  
  1154. 4.5.2.7   Multiplexing on network connection.
  1155.  
  1156.    Multiplexing of Class 4 connections on a single network
  1157.    connection may be used as necessary or useful, within the limits
  1158.    permitted by the network service.  Class 4 connections should not
  1159.    be multiplexed onto network connections serving Class 2 transport
  1160.    connections.
  1161.  
  1162. 4.5.2.8   Concatenation of protocol data units.
  1163.  
  1164.    Concatenation may be useful when operating over a CLNS that has
  1165.    large capacity service data units.  Concatenation on networks
  1166.    that areconnection-oriented may be useful if transport
  1167.    connections are being multiplexed.  A careful analysis of the
  1168.    treatment of the network service data unit in internetwork
  1169.    environments should be done to determine whether concatenation
  1170.    of TPDUs provides sufficient benefit to justify its usage in
  1171.    those circumstances.
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177. McCoy                                                          [Page 20]
  1178.  
  1179. RFC 1007                                                       June 1987
  1180.  
  1181.  
  1182. 4.5.2.9   Checksum algorithm.
  1183.  
  1184.    It is strongly recommended that the algorithm described in the
  1185.    Implementors Guide Part 7, be used rather than the algorithm
  1186.    given in the Annex to IS 8073.  The algorithm in  Part 7
  1187.    computes the same checksum as the one in IS 8073 but  has been
  1188.    optimized.  Guidance on the use and non-use of  checksum is
  1189.    given in the Implementors Guide, Part 7.
  1190.  
  1191. 4.5.2.10   Send network RESET when bad checksum received.
  1192.  
  1193.  
  1194.    It is recommended that only an N-RESET be sent when encountering
  1195.    a TPDU with a bad checksum on a CONS.  An implementation shall
  1196.    not send an N-DISCONNECT-request in such situations, since the
  1197.    TPDU with the bad checksum may have come from some entity
  1198.    intending to interfere with communications.  When  operating
  1199.    Class 4 over a CLNS, no action shall be taken on the receipt of
  1200.    a TPDU with a bad checksum,  i.e., the TPDU shall be discarded.
  1201.  
  1202. 4.5.2.11   Protocol data unit retransmission policy.
  1203.  
  1204.    (The provisions of this paragraph are under consideration.)
  1205.  
  1206. 4.5.2.12   Treatment of protocol errors.
  1207.  
  1208.    In Class 4, a protocol error arising from a TPDU containing
  1209.    unrecognized parameters shall cause a DR TPDU to be sent to the
  1210.    sender, if the TPDU is otherwise valid.  All other erroneous TPDUs
  1211.    shall be discarded.
  1212.  
  1213. 4.5.2.13   Action on receipt of Error transport protocol data unit.
  1214.  
  1215.    If an ER TPDU is received from a remote transport entity, an
  1216.    implementation to which this supplement applies shall release the
  1217.    transport connection with which the ER TPDU is associated, if such
  1218.    association can be made.  When association cannot be made, the ER
  1219.    TPDU shall be discarded.
  1220.  
  1221. 5. SPECIAL REQUIREMENTS
  1222.  
  1223. 5.1   Addressing conventions.
  1224.  
  1225.    (The provisions of Paragraph 5.1 and its subparagraphs are under
  1226.    consideration.)
  1227.  
  1228. 5.1.1   Transport Service Access Point.
  1229.  
  1230. 5.1.2   Connect-request/confirm protocol data units.
  1231.  
  1232. 5.1.3   Network Service Access Point.
  1233.  
  1234.  
  1235.  
  1236. McCoy                                                          [Page 21]
  1237.  
  1238. RFC 1007                                                       June 1987
  1239.  
  1240.  
  1241. 5.2   Convention for use of transport connection reference numbers.
  1242.  
  1243.    The ISO Transport Protocol provides for freezing reference numbers
  1244.    by means of a timer, so that re-use of a reference number does not
  1245.    cause ambiguity in communications. However, certain requirements
  1246.    are imposed on DOD implementations, so that this means of reference
  1247.    number control is inadequate alone. The ISO standard defines only
  1248.    those actions to be followed if a timer is used.  Other means of
  1249.    reference number control are not prohibited, providing that the
  1250.    minimum freeze time, as defined in IS 8073, is exceeded for each
  1251.    reference number used.
  1252.  
  1253. 5.2.1   Specification of convention.
  1254.  
  1255.    An implementation adhering to the applications definitions in
  1256.    this supplement, Paragraph 1.3, shall not re-use a transport
  1257.    connection reference number until the set of available reference
  1258.    numbers has recycled to that point.  Expressed more formally,
  1259.    if all reference numbers are defined to be within the interval
  1260.    [1,N] and a reference number R in this interval is used, then
  1261.    R shall be prohibited from being selected again until all the
  1262.    numbers R+1,...,N,1,2,...,R-1 shall have been used.  The choice
  1263.    of N should be sufficiently large that the expected recycle period
  1264.    exceeds the minimum freeze time as specified in IS 8073.  This
  1265.    requirement is in addition to and does not supersede the freeze
  1266.    requirement of IS 8073.  A simple means of implementing this
  1267.    convention is given in Part 9.3 of the Implementors Guide.
  1268.  
  1269. 5.3  Operation over connectionless network service.
  1270.  
  1271.    Implementations to which this supplement applies are required to
  1272.    operate over connectionless network services in addition to being
  1273.    able to operate over connection-oriented network services. The ISO
  1274.    standard specifies transport only for operation over a
  1275.    connection-oriented network.  However, the specification for Class
  1276.    4 has been written in such a way that use with connectionless
  1277.    network service is not precluded.  The formal description offers
  1278.    even more flexibility in this regard.  Consequently, operation over
  1279.    connectionless network services, whether a LAN or IP, is primarily
  1280.    an implementation issue for Class 4.  Operation of Class 2
  1281.    transportover a connectionless network service is not considered
  1282.    to be a reasonable  option because of the lack of sufficent error
  1283.    recovery in Class 2.   For the purposes of this supplement,
  1284.    operation of Class 2 on a  connectionless network service is
  1285.    not recommended. Operation of Class  4  over a connectionless
  1286.    network service is discussed further in parts 1.2.2.2,  3.4,
  1287.    and 6 of the accompanying Implementors Guide.
  1288.  
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294.  
  1295. McCoy                                                          [Page 22]
  1296.  
  1297. RFC 1007                                                       June 1987
  1298.  
  1299.  
  1300. 5.4   Recovery from peer deactivation.
  1301.  
  1302.    The ISO Standard does not provide for re-establishment of the
  1303.    transport connection  when one of the communicating peers is
  1304.    deactivated ("crashes").  However, the state tables for Class
  1305.    4 transport in Annex A to IS 8073  are flexible enough that
  1306.    simple adaptations in an implementation can yield some degree
  1307.    of crash recovery without change to the protocol.  These
  1308.    adaptations are discussed in Part 9.2 of the Implementors Guide.
  1309.  
  1310.  
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346.  
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354. McCoy                                                          [Page 23]
  1355.  
  1356.